On the Impact of Warmup Phases on the Economics of Pair Programming

Pair programmers need a” warmup phase” before the pair can work at full speed. We study how large the impact of the lower productivity during warmup is on the business value of a pair programming project. To this end, we extend our net present value model for pair programming to explicitly include a learning interval for pairs. We then carry out a simulation study where we vary the shape of the learning curve, the length of the learning interval, the final productivity level of the pairs, the market pressure, and the size of the workforce. Our simulations show that the cost of the warmup phase is small compared to the project value. This result suggests that the learning overhead is not an obstacle to introducing and using pair programming. 1. Current Interests Both of us (Frank and Matthias) are interested in the economic analysis of development techniques and paradigms, such as XP. The goal of our studies is to develop guidelines how to use certain technology in software engineering to the best advantage. Frank also is working on cost estimation and optimal scheduling for software projects. This is a hard problem since feedback between activities introduces a considerable amount of uncertainty into the software process, see [6-9]. Our group in Karlsruhe is known for its long-standing substantial research in empirical software engineering. Matthias has contributed a number of empirical studies about XP to our group’s repository, for example, a study which compares pair programming against conventional development with reviews [13,14]. 2. Past Work Frank is an early member of the EDSER community. He contributed papers on probabilistic cost modeling and the impact of product features (such as the strength of the coupling in the software) on the project cost to the workshops [1-3]. Later on, Matthias joined in to work on the economics of pair programming and extreme programming [4,5]. These papers use concepts from finance such as net present value and return on investment. Expanded versions appeared at international conferences [10,11]. 3. Issue Statement Pair Programming (PP for short) is a technique where all tasks are performed by pairs of developers using one keyboard, display, and mouse. The idea is that working in pairs increases productivity and improves the software quality as compared to conventional development. These potential advantages are reached at the expense of a higher personnel cost, though. Hence, the decision to apply PP in a project must be supported by a classical cost-benefit analysis. There is empirical evidence that developers who program in pairs need a “warmup phase” before PP becomes fully effective, that is, before the pair works at full speed [17,19,20]. We have made similar observations in our XP lab courses for computer science graduate students [15,16]. Human factors are of key importance in this context; some developers easily communicate and share ideas, others don’t. Clearly, the lower productivity of a pair during the warmup phase affects the economic assessment of the project. This holds both for developers who have no experience with PP and those who do, but are member of a newly formed pair. We speak of the “learning phase” in the first case and the “startup phase” in the second case. We expect that the learning phase for PP newcomers will take longer and exhibit a different learning curve than the startup phase for experienced pair-programmers. The questions which we want to study, then, are: • How large is the impact of the lower productivity during warmup on the business value of a pair programming project? • How can the cost of inducting personnel into pair programming be minimized? Type of issue The questions under study are strategic w/t the cost of introducing PP in a company for the first time, but operational w/t estimating the value of individual PP projects and estimating the cost of forming new pairs. The questions relate to business, management, and process issues. The decisions to be made will be mostly non-technical in nature. Context The context of the issues studied in this paper are Agile Methods, in particular, Extreme Programming (XP). Pair Programming is a key technique of XP which can be applied independently of other XP techniques (such as test-driven development). Both XP and PP are being recommended especially for projects which are carried out under strong market pressure. Since programmer pairs should finish tasks faster than single developers, projects which use PP should get to market earlier than conventional projects. The resulting gain in market share can – under suitable conditions, see our previous studies [10,11] – more than balance the increased personnel cost. Stakeholders Main stakeholders are project managers who.... • must decide from an economics perspective whether to switch to PP in their projects; • must estimate the business value of their next PP project; • must introduce new personnel to PP with the lowest possible overhead. We aim at providing project managers with tools for computing the business value of PP projects, methods of tradeoff analysis for PP, and guidelines for using PP. Other stakeholders are.... • developers who must pair-off with new colleagues from time to time; • researchers who want to understand the tradeoffs involved in PP and who aim at increasing the productivity of pairs through suitable tools and techniques. Information needs We need both qualitative and quantitative data about the shape of the learning curves involved in pair programming. In addition, we need numbers for the productivity of pairs for different (industrial) project settings. When applying the model, a manager also needs some estimate of the discount rate appropriate to model the market pressure for his next project. 4. Proposed Approach Research methods We have already constructed and used an economic model for Pair Programming in previous papers [10,11]. The model is based on the concept of net present value (NPV) and has a number of parameters, including the productivity of pairs, the size of the workforce, the market pressure as modelled by the discount rate, and the size of the software product; see below for details. Currently, our model assumes that the productivity of pairs is constant throughout the project. We propose to extend this model to explicitly include a learning interval, respectively, startup phase. The productivity of the pairs should increase according to some learning curve until their final productivity level is reached. Based on such an extended model, we propose to carry out a comprehensive simulation study to analyze what happens to a PP project’s buiness value when we systematically vary .... • the shape of the learning curve and the length of the learning interval; • the final productivity level of the pairs; • the market pressure; • the size of the workforce; • the size of the product. Assumptions The productivity of a pair ususally is expressed as a (fractional) multiple of the productivity of a single developer. The corresponding factor is called the pair speed advantage (PSA). The PSA typically ranges between 1.0 (no difference in productivity) and 2.0 (double speed). In this study, we’ll make the following assumptions w/t the PSA: • We assume that a pair gets more and more productive each working day; that is, we assume that a pair’s PSA value steadily increases from 1.0 to the final value over time. • We assume that the growth of productivity during the warmup phase a priori is described by some learning curve. An s-shaped curve assumes that the pair productivity will increase only slowly in the beginning, but later on will increase quickly as the developers get to know each other better. The formula is a e b − ⋅ + 1 1 ( 0 > a , 1 > b ). An exponential curve assumes that the pair productivity will quickly increase right from the beginning. The formula is a e − − 1 ( 0 > a ). Both curves reach a saturation level after some time and are commonly used to describe human learning processes. The next figure shows two examples for learning curves where the PSA grows from 1.0 to 1.6: • We assume that pairs work with a constant speed after the learning or startup phase; that is, a pair’s productivity (and hence, PSA) will be constant after warmup. This is a natural assumption for coarse-grained models such as our NPV-based model. Process or solution We quickly summarize our existing economic model for pair programming and its extension with an explicit learning or startup phase. The net pesent value (NPV) of a project is defined as ( ) DevCost. te DiscountRa AssetValue NPV DevTime − + = 1 With net present value, the money paid by the customer for the final product (AssetValue) is discounted back at a certain DiscountRate. It is common in economics to model strong market pressure by large values for the discount rate. The development time DevTime (in working days) for a project of size ProductSize (in lines of code) solves the equation e. ProductSiz NumOfPairs PSA ty Productivi DevTime = ⋅ ⋅ ⋅ The development cost (DevCost) for the project is basically proportional to the development time, number of pairs, and developer salary, see [11]. We now extend the model by assuming that the pair speed advantage varies from day to day. The amount of work accomplished on day t then equals NumOfPairs PSA ty Productivi ⋅ ⋅ ) (t where PSA (t) is the value of the pair speed advantage on day t. Therefore, the development time in days for a pair programming project becomes the smallest number DevTime which solves the inequality